Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-180.txt

Text File | 1994-12-08 | 43.1 KB | 1,150 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 09 Oct 92       Volume 1 : Issue 180

Today's Topics:

    Storing Windows
    THINK C 5.0 Code overflow
    GCC under MPW Shell.
    Altering the TRAP dispatch table.
    how to put indelible serial# in resource fork of app?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Jerome Chan)
Subject: Storing Windows
Date: 26 Jul 92 17:21:46 GMT
Organization: Alethea, The Twilight World!


 Is there a way to store windows efficiently? If we use

  GetNewWindows(RESOURCE,NULL,WINDOW_LOCATION) ;

the window would be stored as non-relocateable. Is there anyway we can
use handles to store the window data?

- ---
 The Evil Tofu

"No Lah! Sure or not one? Dunno leh! Nebber Mind! Like that one!
Terriblur Lah!"

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 26 Jul 92 21:59:08 GMT
Organization: Taligent

In article <[e-mail]>, Jerome Chan
<[e-mail]> writes:
>
>  Is there a way to store windows efficiently? If we use
>
>   GetNewWindows(RESOURCE,NULL,WINDOW_LOCATION) ;
>
> the window would be stored as non-relocateable. Is there anyway we can
> use handles to store the window data?

No. WindowRecords contain an embedded GrafPort. According to Technote #155,
GrafPorts should not be allocated in relocatable buffers.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Christ Leijtens)
Subject: THINK C 5.0 Code overflow
Date: 27 Jul 92 16:08:00 GMT
Organization: Erasmus Universiteit Rotterdam



                              THINK C 5.0                    7-27-92



   Dear Netters,

         As beginners at programming the Macintosh Quadra system  we
   have  a  question about THINK C 5.0. We are porting a system pro-
   grammed in the language C under the  operating  system  UNIX.  We
   have  to port the program into THINK C 5.0 on the Macintosh (Qua-
   dra 900 using System 7).

         The system we are porting is quit big.  When  compiling  we
   get the error message:
   Code overflow

   After reading the THINK C 5.0 User Manual we found out it had  to
   do  with the maximum code-length of one C source-file. The manual
   says:

   You have more than 32K of code or data in one  file.  Break  your
   file up into smaller files.

   We tried to split the files giving the code overflow  errors.  It
   seemed,  not  the  sources  where the real trouble, but the (big)
   header files. We did not succeed at splitting the  files  to  get
   rid of the errors.

         Question: Is there *any* way to get around this  bound  for
   the  code and data, so we can continue porting the program to the
   Macintosh? We would like any information on porting programs from
   other implementation of the C-language to Macintosh THINK C 5.0.

         Thanks in advance. Greetings,



                                         Young Ryu & Christ Leijtens

- --
    e-mail:    [e-mail]          _(.~\  ____
           [e-mail]         /_|  /_/\/\/\__
                                                > _/\/\/\/\/
                           /_/ \/\/\/\_\
- --
    e-mail:    [e-mail]          _(.~\  ____
           [e-mail]         /_|  /_/\/\/\__
                                                > _/\/\/\/\/
                           /_/ \/\/\/\_\

+++++++++++++++++++++++++++

From: [e-mail] (Nikolaus E Schuessler)
Organization: Iowa State University, Ames, IA
Date: Mon, 27 Jul 1992 17:22:49 GMT

In article <[e-mail]> [e-mail] (Christ Leijtens) writes:

>         Question: Is there *any* way to get around this  bound  for
>   the  code and data, so we can continue porting the program to the
>   Macintosh? We would like any information on porting programs from
>   other implementation of the C-language to Macintosh THINK C 5.0.
>

Yes, there is... You have to declare all arrays as pointers to arrays
and malloc them in a routine at the start of your program... A * real *
pain ...

char x[1000];

to char *x;

...

x = (char *) malloc(1000 * sizeof(char))

>--
>    e-mail:    [e-mail]          _(.~\  ____
>           [e-mail]         /_|  /_/\/\/\__
>                                                > _/\/\/\/\/


Like your turtle ...

- --
Niko Schuessler
Project Vincent Systems Manager              email: [e-mail]
Iowa State University Computation Center     voice: [phone]
Ames IA 50010                                snail: 272 Durham

+++++++++++++++++++++++++++

From: [e-mail] (Joshua Rabinowitz-Summer-91)
Organization: NASA/ARC Information Sciences Division
Date: Mon, 27 Jul 1992 18:28:27 GMT

In article <[e-mail]> [e-mail] (Nikolaus E Schuessler) writes:
>In article <[e-mail]> [e-mail] (Christ Leijtens) writes:
>
>>         Question: Is there *any* way to get around this  bound  for
>>   the  code and data, so we can continue porting the program to the
>>   Macintosh? We would like any information on porting programs from
>>   other implementation of the C-language to Macintosh THINK C 5.0.
>>
>
>Yes, there is... You have to declare all arrays as pointers to arrays
>and malloc them in a routine at the start of your program... A * real *
>pain ...
>
>char x[1000];
>
>to char *x;
>
>...
>
>x = (char *) malloc(1000 * sizeof(char))


Ummm, are you sure this is what you mean?  it gets an array of 1000 chars
from local memory, then again from malloc.  In addition, isn't x, as declared,
a constant pointer (my language may be incorrect, but i STRONGLY suspect
               the above code of being not what you meant).

What I think you menat was

{
 ...
 char *x;
 x = (char *) malloc(1000 * sizeof(char));

}

right?
>


- --
- ----------------------------------
#include <std/disclaimer.h>     Josh Rabinowitz, Mac TCL programmer
[e-mail]
"'I see', said the blind carpenter, as he picked up his hammer and saw".

+++++++++++++++++++++++++++

From: [e-mail] (Nikolaus E Schuessler)
Date: 27 Jul 92 19:31:50 GMT
Organization: Iowa State University, Ames, IA


>
>What I think you menat was

sed s/menat/meant/ :-)

>
>{
> ...
> char *x;
> x = (char *) malloc(1000 * sizeof(char));
>
>}

Yeah.. I though I put 'You should change a declaration like...' in front of the
char x[1000];

sorry...



- --
Niko Schuessler
Project Vincent Systems Manager              email: [e-mail]
Iowa State University Computation Center     voice: [phone]
Ames IA 50010                                snail: 272 Durham

+++++++++++++++++++++++++++

From: [e-mail] (HP48SX Archive Maintainer)
Date: 28 Jul 92 11:26:22 GMT
Organization: Washington University in Saint Louis, MO USA

[e-mail] (Nikolaus E Schuessler) writes:

>In article <[e-mail]> [e-mail] (Christ Leijtens) writes:

>>         Question: Is there *any* way to get around this  bound  for
>>   the  code and data, so we can continue porting the program to the
>>   Macintosh? We would like any information on porting programs from
>>   other implementation of the C-language to Macintosh THINK C 5.0.
>>

>Yes, there is... You have to declare all arrays as pointers to arrays
>and malloc them in a routine at the start of your program... A * real *
>pain ...

OR

You can go get MPW C which handles large code and data spaces without
the same limitations as THINK C. You get a slower compiler though, but
lots of other good stuff.
- --
Povl H. Pedersen             [e-mail]
HP48sx archive maintainer

All Opinions (C) Copyright the Integalactic Thought Association

+++++++++++++++++++++++++++

From: [e-mail] (Paul McIlroy)
Date: 28 Jul 92 10:23:50 GMT
Organization: British Telecom

Christ Leijtens ([e-mail]) writes
>  Is there *any* way to get around the 32K bound for
>  the  code and data, so we can continue porting the
>  program to the Macintosh?

If no individual array or structure is bigger than 32K
compile all the declarations separately.  I know this sounds
daft, but it works.

e.g. if you have

10_byte_struct_type a[3000];
12_byte_struct_type b[2000];
16_byte_struct_type c[1500];

then together these will cause a code overflow, but
individually they are OK.

So, split the three declarations into three .c files and
compile them separately (with the far data box checked in
the Set Project Type dialog). Then in the main program
declare a, b and c as external arrays.  I have done
this myself and it works well.

If all else fails you can use malloc as others have
suggested, using static pointers instead of static arrays,
but be careful with linking.  If you have
    extern 10_byte_struct_type a[3000];
in one file it will not link to
    10_byte_struct_type *a;
in another.  You will need to change ALL your array
declarations to pointers, in all your files, which is really
tedious.

Paul McIlroy ([e-mail])

---------------------------

From: [e-mail] ("Glen Lalonde")
Subject: GCC under MPW Shell.
Date: 27 Jul 92 17:59:29 GMT

The MPW shell will work on an SE, if you have a 68030 accelerator card.
(it makes no color QD calls :-)

I recall reading on the newsgroup that the GCC port to MPW requires the
MPW assembler. Is this correct? Can I possibly get around this some how?
I guess GAS was not ported.

Also, are there any text instructions(help files) for the MPW Shell on
a ftp site some place?




+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 28 Jul 92 07:06:37 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] ("Glen Lalonde") writes:

>I recall reading on the newsgroup that the GCC port to MPW requires the
>MPW assembler. Is this correct? Can I possibly get around this some how?
>I guess GAS was not ported.

Yes, Asm is required. GCC is like many unix compilers in that it only converts
to assembly and lets the system's assembler handle the rest. It makes
porting easier.

Not only is Asm required, so are the MPW C 3.1 (not 3.2) headers and libraries,
for which you'll need to look on an older dev. cd. MPW C is also required
to compile it (if you modify the sources; I don't remember if the distribution
includes a binary).

GCC 2.2 is under way, and someday in the (distant) future GAS may be available
also. But don't hold your breath. I'll let the people actually involved say
more.
- --
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett, NOT speaking for anyone. Personal opinion only.

---------------------------

From: [e-mail] ("Glen Lalonde")
Subject: Altering the TRAP dispatch table.
Date: 27 Jul 92 19:11:30 GMT

I need to change the location that one of the OS Traps goes go.
IM detains how to do this, but under sys 7 the effect seems to be local
to that process. Once the application that did the patch exits, the OS Trap
went back to its old value. Is there any way to make the patch GLOBAL and
PERSISTENT?

For now I just figured out the location in memory and patched it via
C. I doubt if the trap table always starts at location $400 in memory
for all models though.

I want to trap BlockMove to a version optimized for the 030, my SE has
a 030 card.

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 28 Jul 92 19:52:18 GMT
Organization: U.C. Berkeley Open Computing Facility

In article <[e-mail]> [e-mail] ("Glen Lalonde") writes:
>I need to change the location that one of the OS Traps goes go.
>IM detains how to do this, but under sys 7 the effect seems to be local
>to that process. Once the application that did the patch exits, the OS Trap
>went back to its old value. Is there any way to make the patch GLOBAL and
>PERSISTENT?
>
>For now I just figured out the location in memory and patched it via
>C. I doubt if the trap table always starts at location $400 in memory
>for all models though.

 ^^^^ I really do hope that's temporary! ^^^^

>I want to trap BlockMove to a version optimized for the 030, my SE has
>a 030 card.

In order for your patch to be active as long as the computer is turned on,
you'll need to write an INIT (er, extension...).  (Is that kinda like
'wetlands' and 'marshes' ?)

Anyway, you're lucky.  Your patch doesn't need to call the system when it's
done.  You just want to totally yank out the existing one.  At startup,
use SetTrapAddress to point to your routine.  This routine should be loaded
as a locked-system heap code resource.  (Not 'CODE', code.)

Be sure to detach the rtesource so you're initextention won't be purged when
the file is closed.  Also remember that BlockMove is register based.

Finally, good luck on beating apple's code.  They write _very tight_ assembly
where it counts.  (Elsewhere they tend to do some rather wierd C++).

- -E. Wylie

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 28 Jul 92 21:41:52 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

@ocf.berkeley.edu (Elizabeth Wylie) writes:

   >I want to trap BlockMove to a version optimized for the 030, my SE has
   >a 030 card.

   Finally, good luck on beating apple's code.  They write _very tight_ assembly
   where it counts.  (Elsewhere they tend to do some rather wierd C++).


The ROMs in the SE are _not_ optimized for the 68030...

- --
      Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden
                  [e-mail]    [phone]

              My cat usually runs around on the roof.

---------------------------

From: [e-mail] (Ralph Gonzalez)
Subject: how to put indelible serial# in resource fork of app?
Date: 20 Jul 92 21:18:21 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


Hi.  I am finishing an application for a client, who would like me to
put a serial number on each copy of the completed application.  This
is no doubt naive of me, but I was planning on using ResEdit to put a
unique serial # in each copy of the app (what a pain!) using a STR
resource.  Unfortunately, any purchaser can easily change this serial
number him/herself using ResEdit.

Is there an easy way to prevent changes to the STR resource, or is
there a better way of doing this?

Thanks a lot for any help,
Ralph
[e-mail]
- --
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: [phone]; Internet: [e-mail]
- --

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Mon, 20 Jul 1992 23:27:38 GMT

[e-mail] (Ralph Gonzalez) writes:
>
>Hi.  I am finishing an application for a client, who would like me to
>put a serial number on each copy of the completed application.  This
>is no doubt naive of me, but I was planning on using ResEdit to put a
>unique serial # in each copy of the app (what a pain!) using a STR
>resource.  Unfortunately, any purchaser can easily change this serial
>number him/herself using ResEdit.

Write a quickie program that lets you select an application with the
standard file box, then have it make n copies, adding a serial number to
each one.  Since it's a quickie, you can hard-code both n and the serial
number to start at, and no one will know the difference but you.  :-)

It's pretty easy to make it "unchangeable."  Make a routine that converts
a 32-bit number into a moderately long (say, a 32-byte) code.  Make it
so ridiculously weird and complicated that no one will ever be able to
figure out what in the heck you're doing.  Then have the app check to be
sure its code can be derived from a real 32-bit number;  if so, that's
the serial number;  if not, put up a nasty message and exit.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I suppose ya don't think I was run over by a streetcar!

+++++++++++++++++++++++++++

From: [e-mail] (Ralph Gonzalez)
Date: 22 Jul 92 18:59:09 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

[e-mail] (Jamie R. McCarthy) writes:

>Write a quickie program that lets you select an application with the
>standard file box, then have it make n copies, adding a serial number to
>each one.  Since it's a quickie, you can hard-code both n and the serial
>number to start at, and no one will know the difference but you.  :-)

>It's pretty easy to make it "unchangeable."  Make a routine that converts
>a 32-bit number into a moderately long (say, a 32-byte) code.  Make it
>so ridiculously weird and complicated that no one will ever be able to
>figure out what in the heck you're doing.  Then have the app check to be
>sure its code can be derived from a real 32-bit number;  if so, that's
>the serial number;  if not, put up a nasty message and exit.

Thanks, and thanks to the others who responded via email.  The consensus
was that I should write a program which sticks serial#'s into the
resource fork (or the data fork!) of the applications.  The serial#'s
should be encrypted and a checksum should be embedded in the resource
as well.  Preferably this info should be in a non-obvious place,
such as a CODE resource.  Several interesting alternative schemes
were suggested as well.

Also, it appears to be a good idea to have the user enter their name
the first time they run the program, and display it in the startup
screen after that.  This helps "shame" non-registered users.

QUESTION 1:  Is it ok to store this name in the application's own
resource fork?  I know this is normally discouraged since the app
may be on a read-only fileserver, but for product registration you
don't want to just store it in the Preferences file where everyone
accessing the fileserver gets to register their own name...

QUESTION 2:  It occurs to me that if someone is going to get hold of
someone else's serial#, then they will probably steal this person's
copy of the software as well.  Therefore it doesn't help that each
copy of the software has its own serial# encoded into it.  Rather, it
should be sufficient to have the application request a serial #, and
run it through a scheme (such as that suggested by Jamie McCarthy,
above) which checks if it is a valid serial# -- RATHER THAN CHECKING
IF IT IS THE "CORRECT" ONE.  For example, ask for a 10-digit number
of which only 1000 combinations are valid (assuming you won't sell
more than 1000 copies!).  This saves you from having to attach a
unique serial # to each copy, and bundle it with a manual containing
the correct serial # -- a hassle if someone else is doing the
duplication for you.  Is this a common approach?

- -Ralph

- --
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: [phone]; Internet: [e-mail]
- --

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 22 Jul 1992 20:20:36 GMT

[e-mail] (Ralph Gonzalez) writes:
>
>Also, it appears to be a good idea to have the user enter their name
>the first time they run the program, and display it in the startup
>screen after that.  This helps "shame" non-registered users.
>
>QUESTION 1:  Is it ok to store this name in the application's own
>resource fork?

Try the data fork.  When your app starts, check the data fork to see if
name/company info is there.  If not, try opening your data fork with
fsRdWrPerm.  If you can, request the name/company from the user and
write it in.  If you get a wPrErr or an accessDenied error, you may be
on a CD-ROM, a locked floppy, or a server with read-only access;
no sweat, don't do anything.  If you get an fLckdErr, the file
is locked--tell the user to unlock the app for registration purposes and
ExitToShell.  That way, users can't defeat annoying registration notices
by just locking your app.  If they want to run off a locked floppy or a
read-only folder on a server, then they're obviously quite dedicated to
not seeing that annoying registration, and you won't stop them anyway.
:-)

Don't sweat this too much.  If people want to steal your program, they
will, and there's nothing you can do about it.  Don't spend too much
time worrying about it, and don't annoy legitimate users with whatever
scheme you do implement.

By the way, a good scheme mentioned in AppleDirect once is:  make a menu
item that creates a demo copy of your app.  Then when someone asks a
customer for a copy, s/he can say "sure" and quickly make a sample.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 He let the contents of the bottle do the thinking
 Can't shake the devil's hand and say you're only kidding            - TMBG

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 22 Jul 92 20:43:38 GMT
Organization: U. C. Berkeley Open Computing Facility

I have a cool piece of shareware on my hard disk which seems to handle this whole name/serial number thing quite well.

It works entirely on the humiliation-ware concept.  Nobody wants someone else's name emblazoned on their $10 piece of software.  How low can you get?

So anyway the program makes you send in for your super-secret registration code.  This code is a really wierded-out checksum/encryption of your name.

So, for every name, there is a different secret code.  The program won't let you have a mismatching code/serial number.  It'll just say "Unregistered User".

Now, you could incorporate the user's name AND the serial number.  Use a lot of XORs and tricky bit shifting to get a suitable ugly checksum and then convert it to a long (10 digits or so) decimal number.

Anyway, that's what FinderWindows seems to do.  An excellent program, by the way.  It adds a windows menu to the finder and other programs.  Lets me keep 20 or so windows open on my screen and not lose a single one.

(Thanks Damon!)

- -E Wylie

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 23 Jul 92 00:38:50 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Elizabeth Wylie) writes:
> I have a cool piece of shareware on my hard disk which seems to
> handle this whole name/serial number thing quite well.
>
> It works entirely on the humiliation-ware concept.  Nobody wants
> someone else's name emblazoned on their $10 piece of software.
> How low can you get?
>
> So anyway the program makes you send in for your super-secret
> registration code.  This code is a really wierded-out
> checksum/encryption of your name.
>
> So, for every name, there is a different secret code.  The
> program won't let you have a mismatching code/serial number.
> It'll just say "Unregistered User".
>
> Now, you could incorporate the user's name AND the serial
> number.  Use a lot of XORs and tricky bit shifting to get a
> suitable ugly checksum and then convert it to a long (10 digits
> or so) decimal number.
>
> Anyway, that's what FinderWindows seems to do.  An excellent
> program, by the way.  It adds a windows menu to the finder and
> other programs.  Lets me keep 20 or so windows open on my
> screen and not lose a single one.

My shareware program, AppSizer, does something very similar.  Since
it's a INIT/Control Panel, I added one more twist.  In addition to
simply flashing unregistered copy in its windows, it also puts up
a message once a month that reminds them of this fact too.  This extra
prompt will often remind them even after they get used to the unregistered
user message in the windows.  And a number of my registed users mention
that this is what reminded them to register.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Date: 23 Jul 92 02:51:21 GMT
Organization: NCRPDA, Curtin University

In article <[e-mail]>,
[e-mail] (Jamie R. McCarthy) wrote:

> It's pretty easy to make it "unchangeable."  Make a routine that converts
> a 32-bit number into a moderately long (say, a 32-byte) code.  Make it
> so ridiculously weird and complicated that no one will ever be able to
> figure out what in the heck you're doing.  Then have the app check to be
> sure its code can be derived from a real 32-bit number;  if so, that's
> the serial number;  if not, put up a nasty message and exit.

Thats always a fun technique to break that one :-).  A quick atb trap break
in macsbug for the GetNewDialog call, ten seconds later you have the branch
code that checks the validity of the code number, reverse that branch so it
only puts up the dialog if the code number is CORRECT, and thats it.  Then
I delete the app, and sometimes I even mail the authors to thank them for
the entertainment their program gave me :-)

Now, please people if you want to write serial number type stuff here are
some do's and don'ts:

Do make it hard to crack - some of us enjoy a chalenge :-)

Don't make it a pain to install - some of us don't like a chalenge :-)

Don't make it a nightmare for network administrators who have to install
dozens/hundreds of copies of your app - some of us hate a challenge! :-)

If they must register to get the serial name that matches their name,don't
screw up the spelling of their name! - some of us like our names spelled
the way they are suppose to be (anyone heard of a preventatation research
centre?)

Don't make users enter something everytime the program runs - some of us
want to use your program, not memorise code numbers

Don't forget that any form of copy protection will likely get mentioned in
review of your programs, and this may adversly affect sales.

Don't waste network bandwidth on serial number checks - its not your
network to be wasting the bandwidth on, you want to tie up a network, get
your own.

Do be pleasant about it - some of us are not to pleased to see acusing
dialogs everytime we launch an app we paid good money for.

For users: Don't pirate software, and pay for shareware - some of us want
to eat.

ObProgramming: One way to make life difficult for crackers is to use the
serial number to encryp a code resource - store the user's name, and the
users serial number in the data fork, display it in the startup dialog, and
use it to decrypt vital code resources.  Then, checksum the code and if its
not right, put up an alert - that way, even if the branch is removed the
program will just crash (serves those nasty crackers right :-).  Of course,
the virus detectors will probably blow their tops if you go around hacking
with Code Resources.  Aside from which people will quite probably want to
run a single copy of the app off a locked file server...  And for heavens
sake turn macsbug name generation off before you compile it!  I have seen
several commercial apps with names turned on in their code checking code,
pretty impressive guys :-)

Have fun all,
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 23 Jul 1992 09:08:13 GMT

.50.3> [e-mail] (Peter N Lewis) writes:

   ObProgramming: One way to make life difficult for crackers is to use the
   serial number to encryp a code resource - store the user's name, and the
   users serial number in the data fork, display it in the startup dialog, and
   use it to decrypt vital code resources.  Then, checksum the code and if its
   not right, put up an alert - that way, even if the branch is removed the
   program will just crash (serves those nasty crackers right :-).  Of course,

Yes. However, BE SURE TO FLUSH THE CACHE after you've decrypted
the CODE resource. something like
    if ( TrapAvailable ( _HwPriv ) ) {

        FlushDataCache ( ) ;
        FlushInstructionCache ( ) ;
    }

   the virus detectors will probably blow their tops if you go around hacking
   with Code Resources.  Aside from which people will quite probably want to
   run a single copy of the app off a locked file server...  And for heavens

No ! the cool thing is, you do this as a patch to GetResource and
LoadResource, so it's only changed when loaded into memory, not
on disk. Or you could load, move high, and lock the CODE resource
and never let go of it; still only affects memory, not disk.

   sake turn macsbug name generation off before you compile it!  I have seen
   several commercial apps with names turned on in their code checking code,
   pretty impressive guys :-)

I see MacsBug symbols as a user service ! More than once have I had
spontaneous crashes, and only the debugger names helped me figure
out what was going on. Not to mention a dedicated user can provide
excellent feedback for Tech Support if the names still are in there,
like, fixing their bugs :-)

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds.
### You have the 24-bit virus. This virus eats system memory like CRAZY.

+++++++++++++++++++++++++++

From: Ken Wieschhoff <[e-mail]>
Organization: Eastman Kodak Company
Date: Thu, 23 Jul 92 14:51:52 GMT

A good way to keep users from running software from servers is to disable
the capability completely.  When an application is started, doing a
GetVol(  volumeName, &fVRefNum); when the app launches retrieves the
volume reference.  Use the following routine to determine if a vol ref is
a network volume.

pascal Boolean IsNetworkVolume( short vRefNum)
{

    HParamBlockRec pb;
    GetVolParmsInfoBuffer info;
    OSErr err;

    // Flag mask for vMAttrib field
    const long bExtFSVol = 1L << 16;
    pb.ioParam.ioCompletion = NULL;
    pb.ioParam.ioVRefNum = vRefNum;
    pb.ioParam.ioNamePtr = NULL;
    pb.ioParam.ioBuffer = (Ptr) & info;
    pb.ioParam.ioReqCount = sizeof(GetVolParmsInfoBuffer);

    // Get volume info
    err = PBHGetVolParmsSync( &pb);

    // Check this for a network volume.
    if ((info.vMServerAdr != 0) && (err == noErr))
        return true;
    else
        return false;
}


Kenneth H. Wieschhoff, Jr.    | "If you want to f*** with
[phone](w)            | the Eagles, you gotta learn
[e-mail]            | to fly"  -->Heathers

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 23 Jul 92 18:24:17 GMT
Organization: U.C. Berkeley Open Computing Facility

- ---------
A good way to keep users from running software from servers is to disable
the capability completely.  When an application is started, doing a
GetVol(  volumeName, &fVRefNum); when the app launches retrieves the
volume reference.  Use the following routine to determine if a vol ref is
a network volume.
- ---------

To say the least it's a good way to piss off hundreds of your users.  Copy protection is a thing of the past.

OVERCHARGE !   OVERCHARGE !  OVERCHARGE !

E. Wylie
.

+++++++++++++++++++++++++++

From: [e-mail] (Humayun Lari)
Date: 23 Jul 92 19:18:28 GMT
Organization: University of North Carolina, Chapel Hill

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>.50.3> [e-mail] (Peter N Lewis) writes:
>   sake turn macsbug name generation off before you compile it!  I have seen
>   several commercial apps with names turned on in their code checking code,
>   pretty impressive guys :-)
>
>I see MacsBug symbols as a user service ! More than once have I had
>spontaneous crashes, and only the debugger names helped me figure
>out what was going on. Not to mention a dedicated user can provide
>excellent feedback for Tech Support if the names still are in there,
>like, fixing their bugs :-)

Oh, definitely. I was using a release version of a language that should have
stayed in beta for a couple more months -- to be precise, it occasionally
crashed as soon as you tried to run your program. One day, it decided to hang,
and for some inexplicable reason :-) it had been some time since I'd saved.
It was Macsbug time; the only problem was that there was no debugger switch
on the Mac Plus -- it was a public lab, so naturally they didn't want users
accidentally bombing the machine. So <sigh> I stuck the strap of my wristwatch
into the side of the Plus until it hit the switch, looked up the event loop
in Macsbug, and typed something like "g event"...

Amazingly, it worked. :-)


Humayun Lari
([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 23 Jul 1992 21:36:21 GMT
Organization: U.C. Berkeley Open Computing Facility

>I see MacsBug symbols as a user service ! More than once have I had
>spontaneous crashes, and only the debugger names helped me figure
>out what was going on. Not to mention a dedicated user can provide
>excellent feedback for Tech Support if the names still are in there,
>like, fixing their bugs :-)

I think the point the original poster was trying to make was it's much easier to berak copy protection schemes when there are macsbug labels like "CHECKPASSWORD", "COPY_PROTECTION_HERE", "BACKOFF_HACKERS" and "THIS_IS_IT".

On especially large projects you can save several K by not including macsbug names.  Keep 'em in your beta version, not in the final release.

(You *DO* write betas, don't you? And you *DO* have more than one person (your kid sister doesn't count) test for you?)

- -E Wylie
.


+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 23 Jul 92 22:28:29 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.kodak.com> Ken Wieschhoff <[e-mail]> writes:

   A good way to keep users from running software from servers is to disable
   the capability completely.  When an application is started, doing a
   GetVol(  volumeName, &fVRefNum); when the app launches retrieves the
   volume reference.  Use the following routine to determine if a vol ref is
   a network volume.

Do you think users with System 7 file sharing would
ever consider buying your program ?

PLAY BY THE RULES !

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds.
### You have the 24-bit virus. This virus eats system memory like CRAZY.

+++++++++++++++++++++++++++

From: [e-mail] (Ken Wieschhoff)
Date: 24 Jul 92 14:30:47 GMT
Organization: Eastman Kodak Company

>Do you think users with System 7 file sharing would
>ever consider buying your program ?
>
>PLAY BY THE RULES !

What rules?  Buy yer own goddamned copy!  If you're following
the thread, there's concern about placing a serial number
into the resource fork of the fuckin' file.  You don't want
to do that if you're on a network volume do you?

Kenneth H. Wieschhoff, Jr.    | "If you want to f*** with
[phone](w)            | the Eagles, you gotta learn
[e-mail]            | to fly"  -->Heathers

+++++++++++++++++++++++++++

From: [e-mail] (Stephan - Somogyi)
Date: 24 Jul 92 19:35:00 GMT
Organization: The Portal System (TM)

Ken Wieschhoff <[e-mail]> writes:

>What rules? Buy yer own goddamned copy! If you're following the thread,
>there's concern about placing a serial number into the resource fork of the
>fuckin' file. You don't want to do that if you're on a network volume do
>you?

Thank you for your well reasoned response to Jon's comment.

As I recall, your original posting stated that your software would refuse to
launch from a remote volume since it checks whether or not it's on a local
one.

I regularly put tools on a server where I can access them remotely as I
wander around the office carrying a floppy with an alias to the server. If I
encountered software that told me that it would not launch from a server,
even if I was the only launcher of said app and therefore well within my
rights as a single-user licensee, I would take a dim view of this indeed.

I will make sure we know to test this the next time we review certain kinds
of software. I can think of a number of instances where I'd want single-user
server access to some of the DTP tools we use around here. Not farfetched at
all.

As always, my opinions, not my employer's.

_________________________________________________________________________
Stephan Somogyi                  parking vulture                  MacUser

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 23 Jul 92 23:08:56 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

@ocf.berkeley.edu (Elizabeth Wylie) writes:

   On especially large projects you can save several K by not including macsbug names.  Keep 'em in your beta version, not in the final release.

But I'm not a beta tester. I still want to know what goes wrong
and how to fix it !

   (You *DO* write betas, don't you? And you *DO* have more than one person (your kid sister doesn't count) test for you?)

Yes of course. A few Ks don't matter much, and I like getting
mail from people who fix my bugs :-) I want others to feel the
same way since there STILL is bugs in released software.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds.
### You have the 24-bit virus. This virus eats system memory like CRAZY.

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 24 Jul 92 01:21:20 GMT
Organization: U.C. Berkeley Open Computing Facility

In article <[e-mail]> [e-mail] (Jon W{tte) writes:

>But I'm not a beta tester. I still want to know what goes wrong
>and how to fix it !

A good point.

>
>   (You *DO* write betas, don't you? And you *DO* have more than one person (your kid sister doesn't count) test for you?)

>Yes of course. A few Ks don't matter much, and I like getting
>mail from people who fix my bugs :-) I want others to feel the
>same way since there STILL is bugs in released software.

When writing INITs, etc.  I always make sure to keep the names off for the "final" release.  I'm really obsessive about system heap size.  Mine is 4 meg on an 8 meg machine.

It also gives me that "polishedd" feeling when I'm finally done with it.

- -E. Wylie
.

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Organization: NCRPDA, Curtin University
Date: Mon, 27 Jul 1992 09:02:36 GMT

In article <[e-mail]>,
[e-mail] (Jon W{tte) wrote:

>    A good way to keep users from running software from servers is to disable
>    the capability completely.  When an application is started, doing a
>    GetVol(  volumeName, &fVRefNum); when the app launches retrieves the
>    volume reference.  Use the following routine to determine if a vol ref is
>    a network volume.
>
> Do you think users with System 7 file sharing would
> ever consider buying your program ?

I hate to inject some actual technical information in here, especially when
you are refuting an argument that actually suggests programs should
disallow themselves to be run from a server (the stupidest thing I've heard
in a long while, practically every program we have hear we have a single
user license and a single copy on the server with the shared bit off so
only one user can use it at a time), BUT, even under System 7 with file
sharing turned on, the local volumes still have a 0 in the server address
field.  It's most annoying really - does anyone know how to get the
FileSharing port number for the local machine, the only way I've found to
do it is either an PConfirmName('=:AFPServer@*') to this machine (which I
think should actually fail because meta chars are not allowed in
PConfirmName, but seems to work anyway), or NBPLookup('=:AFPServer@*') and
then search thru for the local machine's net/node number.

Have fun all, and don't expect me to pay for (and hence use) any app I
can't use from my server - it'll go straight back for a refund.
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 29 Jul 92 04:50:19 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Stephan - Somogyi) writes:
> I regularly put tools on a server where I can access them remotely as I
> wander around the office carrying a floppy with an alias to the server. If I
> encountered software that told me that it would not launch from a server,
> even if I was the only launcher of said app and therefore well within my
> rights as a single-user licensee, I would take a dim view of this indeed.

Here's another evil twist: a program that requires a serial number the
first time you run it after installation. Then, if you move it to a different
volume (like on a server), it asks for the serial number again!

I'm talking about Mathematica 2.0. I suspect it does something like store
a file or directory ID number in its prefs file. If this doesn't match, it
knows it's running a different copy.

> I will make sure we know to test this the next time we review certain kinds
> of software. I can think of a number of instances where I'd want single-user
> server access to some of the DTP tools we use around here. Not farfetched at
> all.

You might like to add Mathematica's copy protection to your list of things
to check.

"How do I piss the user off? Let me count the ways..."

---------------------------

End of C.S.M.P. Digest
**********************